home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 568 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.2 KB
  1. Subject: Re: pipes & ptys
  2. Date: Wed, 20 Oct 93 22:56:08 CET
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <9310200039.AA03420@pirol.techfak.uni-bielefeld.de>; from "itschere@TechFak.Uni-Bielefeld.DE" at Oct 20, 93 1:39 am
  5. Message-Id: <9310202156.AA00230@jelal.north.de>
  6.  
  7. itschere@TechFak.Uni-Bielefeld.DE writes:
  8. > Juergen Lock
  9. > > 
  10. > > > Well, what else can I do in a Program like a window manager, if I've
  11. > > > got to look for every char?
  12. > > 
  13. > >  well Eric said that already but in different words... :)  a 1k RAW
  14. > > read() does not block until it has read 1k, only until _some_ data is
  15. > > available. (pty master reads are always RAW)  if it receives 200 bytes
  16. > > (i.e. pty slave write()s 200 bytes) it returns 200 bytes, if data comes
  17. > > in 1-byte-at-a-time it reads 1 byte, or whatever has accumulated in the
  18. > > buffer (pipe) since the last read.
  19. > > 
  20. > >  so look at each char does not mean you need one system call for each
  21. > > char...
  22. > 
  23. > Ok, got this, but: (see my other mail) it will return as soon as ther is
  24. > some data, say, when it get's its next time slice, which is 16ms long on
  25. > my 60Hz TT-VBL, right? Now I estimate that the writer (if really (worst case,
  26. > of course, but that's what counts.)) using 1 bytes I/O, doesn't manage
  27. > to output more than something like 30 chars per timeslice, so 60 slices
  28. > a 30 bytes (always completely ignoring the time I need to read the data),~
  29.  
  30.  this is the time we're trying to improve...
  31.  
  32. > makes 1800 CPS, and that looks like the number I've measured.
  33.  
  34.  how much cps does the writer get when you send it to /dev/null
  35. instead?  the difference between that and your 1800 is the only thing
  36. we can improve here of course... for more the writing program has to
  37. use longer writes.
  38. > 
  39. > > >   Point is that system calling overhead is soooo big that it doesn't matter
  40. > > > a lot if the pipefs has got to do 1 or 4 bytes read.
  41. > > 
  42. > >  yes but it doesn't... have to do single-char IO.  and when you have
  43. > > larger read/writes this character shuffling can cause overhead of
  44. > > n times the size of the actual device IO.
  45. > 
  46. > Perhaps we can start a personal dispute about this, but so far I heavily
  47. > doubt this. Sorry, no proofs so far... :-(
  48. > 
  49. > > type            read    write    speed (CPS)    % CPU load (top)
  50. > > -----------------------------------------------------------
  51. > > pipe            4096    4096    270000
  52. > > pty            4096    4096    a bit less
  53. > > 
  54. > >  pty output would get nearly as fast as the pipe, and serial ports could
  55. > > run full speed and no longer eat up all available cycles...
  56. > 
  57. > If a) you really use big chunks and b) modems are operated by interrupt...
  58.  
  59.  yup!  actually modems are operated by interrupts already, only
  60. the buffer status is still polled and data is read/written
  61. one-byte-at-a-time...
  62. > 
  63. > > >  At least at my setup the involved device
  64. > > > drivers can easily be fixed.
  65. > > 
  66. > >  hmm how do you mean that?
  67. > 
  68. > Well, to make the biosfs drives expect char pointers instead longs. None
  69. > of my program _seems_ to complain about this. But obviously that's no
  70. > compatible solution... ;-)
  71.  
  72.  and i guess none of your programs use scan codes...
  73.  
  74.  :-)
  75.     Juergen
  76. -- 
  77. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  78.                                 ...ohne Gewehr
  79. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  80.